It is known to use non-volatile memory (NVM) in processors, computers, and other kinds of devices where information needs to be stored persistently (not being erased by a power cycle). There are various types of NVM, including read-only memory (ROM) such as programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or one-time programmable (OTP) NVM, to give some examples.
The majority of the Systems on Chip (SoC) that include a processing unit also include a type of ROM to store software functions or tables of data. A stored collection of functions usually implements a software library which can be used by an application executed by the processing unit. The storage of a library in ROM reduces the required silicon area that it is needed to store a specific software code on-chip, reducing thus the final cost of the SoC product.
Data stored in ROM and other types of NVM cannot be easily altered. However there are cases where it is desired to alter the contents of this type of memory. For example, there are cases where the software functions stored in ROM do not behave as expected. This can be very serious if a bug is only found after the manufacturing of the SoC. Because the information stored in the ROM is mask-programmed, it is not possible to change and fix those functions.
As a solution to this it has been proposed to provide ROM patching mechanisms, which prevent execution of defective code in the ROM by the processor and provide corrected code which is executed instead.
There are software based patching mechanisms that make use of specific software structures in order to provide the patching feature. They typically select a very limited number of functions located in ROM, which suspected as being prone to failure or may be critical for the system operation. Then they can replace all the calls to this limited number of functions with a code that fetches the final base address from a table located in the RAM. Another solution is to replace all the calls to these functions with a call to “hook” functions, one for each function to be able to be patched, which are located in RAM and include only a call to the final function body. If after the manufacturing of the SoC an error will be detected in these functions, then the table with the function pointers, or the alternative hook functions could be modified, redirecting thus to the correct function located in RAM, replacing the one in ROM. Other similar implementations may be used as well, but a drawback of the software based solutions is that they require more area in the code memory, they consume more execution cycles (reducing thus the response time of the system) and they provide the option to patch only a limited number of functions.
A hardware based patching system has been disclosed in US 2014/0289455, in which an address register stores an address referring to a word located in ROM, which corresponds to a word that needs to be patched, which stores either instructions or data. Another data register stores a single data word or instruction to be used in place of the defective data stored in the ROM. The hardware tracks all the transactions on the system bus, and when there is a memory transaction referring to the address that has been programmed to the address register, then the patch circuit replaces the data on the bus with the word programmed in the data register. Patching directly from the data register means that the processing unit's execution delay is not affected by the patching. However, this system requires a lot of extra area on the circuit substrate and only allows for a limited number of memory positions to be patched. Also, in case of patching a function, the efficiency of this circuit is strongly dependent on the Instruction Set Architecture (ISA) of the given processing unit.